feat(kernel): thread Azure Entra OAuth (U2M + SP M2M) through the auth bridge - #919

🟡 Medium — The azure-oauth (and azure-sp-m2m) branches return before the ambiguity guards run, so conflicting signals that are rejected for the non-Azure U2M path are silently accepted for Azure.

Concretely, auth_type="azure-oauth" + oauth_client_secret reaches this branch, builds oauth-u2m kwargs, and returns — the secret is silently discarded and the browser flow runs. The exactly-parallel non-Azure case (auth_type="databricks-oauth" + oauth_client_secret) instead raises NotSupportedError("Ambiguous auth ...") a few lines below. The same gap lets azure-oauth + a custom credentials_provider bypass the credentials_provider-ambiguity guard. This is also a behavior regression: the prior code rejected any azure-oauth request up front, so a mis-specified azure-oauth + secret used to fail loudly and now succeeds with a different principal/flow than the caller likely intended.

Consider applying the same ambiguity checks (secret-with-U2M, credentials_provider-with-secret) to the Azure U2M branch before returning, so an ambiguous Azure request fails at session-open rather than silently choosing the browser flow.

🔵 Low — The azure-oauth branch returns before the section-0 ambiguity guards, so it silently ignores auth signals that the databricks-oauth U2M path rejects loudly. Specifically:

• auth_type="azure-oauth" + oauth_client_secret → routes to U2M and drops the secret, whereas auth_type="databricks-oauth" + oauth_client_secret raises NotSupportedError("Ambiguous auth …").
• auth_type="azure-oauth" + credentials_provider → also silently ignored.

These combinations are nonsensical (Azure M2M is expressed via azure-sp-m2m + azure_client_secret, not oauth_client_secret), so the practical blast radius is small. But for consistency with the U2M guard — and to avoid a confusing silent browser-flow launch when a caller clearly intended a non-interactive credential — consider applying the same ambiguity check to azure-oauth, or documenting the intentional divergence. Not a correctness bug, just an inconsistency in the fail-loud contract.

🟡 Medium — The module docstring here describes azure-oauth as routing → ``oauth-u2m`` with the Azure app client id (``96eecda7-…``), redirect port ``8030``, and the AAD delegated scope ``{app_id}/user_impersonation offline_access`` (via ``AzureOAuthEndpointCollection``…). That does not match what the code actually does. The azure-oauth branch (line 226) forwards auth_type="azure-oauth" (not oauth-u2m) and constructs none of those values — the inline comment at lines 218–225 explicitly states "this binding does NOT construct endpoints/scopes — it just passes auth_type='azure-oauth' plus any optional client_id / redirect_port passthrough" and that the kernel pins the client id / port 8030 / scope.

So the top-of-file docstring directly contradicts both the executable code and the inline comment beside it: it claims the bridge maps to oauth-u2m and synthesises the Azure bundle, when in fact it delegates all of that to the kernel via the azure-oauth selector. A maintainer reading the module docstring will expect AzureOAuthEndpointCollection.get_scopes_mapping to be called here (it never is on this path). Please align the docstring with the actual selector-forwarding behavior.

🔵 Low — Asymmetric handling of auth_type + oauth_client_secret. For databricks-oauth, supplying oauth_client_secret (a U2M selector plus an M2M secret) is deliberately rejected as "Ambiguous auth" so it doesn't silently authenticate against the wrong principal. But the azure-oauth branch runs before those guards and simply ignores any oauth_client_secret present, silently proceeding with the U2M browser flow. Given azure-oauth is newly supported here, the same class of conflicting-signal request should arguably fail loudly for consistency rather than be silently dropped.

(Anchored to the nearest changed line — see the description for the exact location.)

🔵 Low — The TestKernelOAuthU2M class docstring points readers to test_azure_oauth_routes_to_kernel_u2m, but no such test exists. The azure-oauth tests are actually named test_azure_oauth_forwards_selector_kernel_owns_resolution and test_azure_oauth_honors_custom_client_id_and_port. Update the cross-reference so it names a real test.

🟡 Medium — The new hostname parameter is never used. kernel_auth_kwargs now accepts hostname (line 152) and client.py was changed to pass self._server_hostname, but the function body never references hostname on any code path — the azure-oauth and azure-sp-m2m branches forward the selector/creds verbatim and let the kernel own resolution.

The PR description says the param exists "for the effective Azure app id per cloud," which matches the intent behind the test-file import of get_effective_azure_login_app_id — but that computation was ultimately delegated to the kernel, leaving this parameter (and the client.py threading) as dead plumbing. Either drop the parameter and the client.py call-site change, or use it. Threading a value in that the function ignores invites future readers to assume it affects resolution when it does not.

🔵 Low — get_effective_azure_login_app_id is imported here but never referenced anywhere in the test module (the TestKernelAzureSpM2M suite asserts only on the thin-forwarding kwargs, which don't involve the effective app id). This is an unused import — flake8/linters will flag it, and it's a leftover from an earlier design where the bridge computed the app id itself. Remove the import.